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1.0. 


INTRODUCTION 


1.1.  OBJECTIVES  OF  THE  STUDY 

1.1.1.  Background 

The  production  of  maintenance  Technical  Orders  (T.O.),  Job  Guides,  Illustrated 
Parts  Breakdown  Manuals,  and  related  publications  account  for  a  large  share  of  the  cost  of 
weapon  system  acquisition.  1  Informal  estimates  put  this  cost  as  much  as  fifteen  percent  of 
the  total  acquisition  cost  for  major  new  systems.  But  high  cost  isn’t  the  only  problem. 

T.O.’s  are  often  delivered  late  to  the  field.  And  after  they  arrive,  they  are  often  found  to  be 
inaccurate  or  incomplete.  Updating  this  documentation  as  weapon  systems  are  modified  is 
a  continuous  and  cumbersome  process. 

Investments  in  data  automation  over  the  past  decade,  through  CALS  and  related 
initiatives,  have  moved  T.O.  publications  and  other  weapon  system  information  from  a 
bulky,  paper  past  toward  a  streamlined,  digital  future.  T.O.s  have  begun  to  appear  in 
electronic,  interactive  formats.  Legacy  data  is  being  converted  to  digital  forms  to  make  data 
management  for  weapon  system  support  easier  and  less  costly. 

Despite  these  improvements,  technology  support  for  original  technical  data 
production  remains  relatively  primitive.  The  T.O.  “author”  confronts  an  assortment  of  design 
and  logistics  information  sources,  a  mix  of  automated  and  “manual”  work  tools,  and  a  long 
list  of  other  players  who  hold  vital  information  and  expertise.  She  must  pool  the 
contributions  of  design  engineers,  logistics  and  maintenance  experts,  draftsmen,  and  others 
to  create  maintenance  technical  data.  This  has  never  been  an  easy  task,  and  modern 
“lETM”  workstations,  while  helpful,  have  not  reduced  the  cost  or  shortened  the  time  line  for 
original  tech  data  production.  Large  productivity  gains  in  the  future  can  only  come  from 
automation  support  for  the  tech  data  development  prqcess  in  the  first  place. 

1.1.2.  Purpose 

This  paper  describes  some  aspects  of  automation  support  used  in  the  creation  of 
maintenance  information.  It  has  a  pragmatic  outlook.  The  various  advantages  and 
drawbacks  of  automation  are  viewed  from  the  perspective  of  actual  maintenance  technical 
writers  in  the  defense  industry.  We  attempt  to  define  a  set  of  automation  needs  without 
specifying  the  specific  solutions.  The  objective  is  to  establish  a  baseline  for  research  and 
technology  development  to  address  practical  problems  in  the  real  world. 


’  In  this  paper  we  use  the  terms  Technical  Orders,  T.O.,  and  tech  data  interchangeably.  Job  Guides, 
Illustrated  Parts  Breakdown  Manuals,  Troubleshooting  Manuals,  and  other  types  of  publications  are 
included  under  these  terms. 
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2.0  EXECUTIVE  SUMMARY 


Creation  of  technical  manuals  requires  information  assembled  from  a  wide  variety  of 
sources.  These  include:  (a)  manufacturing  design  data  to  provide  illustrations  of  various 
hardware  assemblies;  (b)  diagnostic  design  data  to  provide  troubleshooting  methods  and 
subsystem  checkout  procedures;  and  (c)  logistics  data  to  enumerate  parts  and  materials. 
The  main  difficulty  in  reusing  these  sources  of  information  in  technical  publications  is  that 
they  are  dispersed  and  not  organized  for  the  purpose.  Rather  than  a  lack  of  information, 
the  problem  has  more  to  do  with  collecting  and  combining  the  information  that  already  exists 
in  useable  formats.  Figure  2.1  illustrates  the  central  problem  facing  the  technical  order 
author. 


Process  Specifications 


Technical  Order 
Author 


Retrofit  Sketches 


Figure  2.1.  Multiple  Sources  of  Information 


Initiatives  are  under  way  to  directly  address  the  problem  of  organizing  and 
integrating  heterogeneous  data.  They  can  be  summed  up  in  the  notion  of  a  Product  Data 
Manager  (PDM),  a  system  to  handle  all  product-related  information,  including  text,  video, 
and  multimedia  files,  in  a  common  data  repository.  Engineering  design  analysis  and 
simulation  tools  will  use  PDM  as  inputs.  Results  of  these  “virtual”  simulations  and  analyses 
can  be  recorded  as  outputs  captured  by  the  PDM.  The  following  two  examples  illustrate 
possible  scenarios  for  collecting  procedural  and  fault  data,  key  data  elements  for  Technical 
Orders. 

Fault  Data.  The  following  example  illustrates  one  possible  scenario  for  collecting 
testing,  and  troubleshooting  data  for  an  aircraft  fuel  system.  A  fuel  system  designer  creates 
an  initial  model  of  his  system  in  Computer  Aided  Design  (CAD)  or  other  design  aids.  When 
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an  initial  system  configuration  has  been  achieved  the  design  data  will  be  stored  in  a 
database  where  it  can  be  accessed  by  other  tools.  The  designer  (or  another  engineer) 
would  then  analyze  system  performance  using  Computer  Aided  Engineering  (CAE) 
simulation  tools.  Based  on  the  results  of  that  analysis,  several  iterations  between  the 
design  and  performance  simulation  tools  may  be  performed.  At  the  same  time,  diagnostic 
and  reliability  tools  can  use  the  data  obtained  from  the  CAE  tools  (describing  system 
connectivity  and  component  behavior)  to  perform  reliability  and  diagnostic  analyses.  Once 
a  stable  system  design  configuration  has  been  achieved,  the  diagnostic  predictive  baseline 
can  be  stored  in  the  diagnostic  database.  Once  stored,  further  diagnostic  development  and 
failure  modes  analyses  can  proceed.  Upon  completion,  the  diagnostic  process  and  failure 
modes  and  effects  analysis,  will  also  be  stored  in  the  diagnostic  database.  This  data  can 
then  be  used  by  an  authoring  tool  to  aid  the  author  in  the  preparation  of  T.O.  Test  Tasks 
and  Outcomes,  Faults  and  Rectifications.  This  is  the  data  that  is  the  most  difficult  (and 
costly)  to  author,  review,  and  maintain. 

Procedural  Data.  The  following  example  illustrates  one  possible  scenario  for 
collecting  procedural  data  (removal,  installation  and  parts  data).  Using  the  same  CAD  data 
developed  in  the  above  scenario,  the  design  engineer  creates  an  initial  model  of  his  system 
in  CAD.  Before  significant  investments  are  made  for  tooling  or  equipment,  the 
manufacturing  engineer  performs  an  analysis  of  the  impacts  to  manufacturing  by  simulating 
the  manufacturing  process,  using  Virtual  Manufacturing  (VM)  simulation  and  modeling  tools. 
Based  on  the  results  of  that  analysis,  several  iterations  between  the  design  and  VM 
simulation  tools  may  be  performed.  Once  a  stable  system  design  configuration  has  been 
achieved,  the  same  VM  tools  could  be  used  to  provide  the  T.O.  author  with  a  graphical 
interface  for  the  development  of  assemble/disassembly  sequences  and  procedures. 

The  technical  path  for  automation  support  of  T.O. s  should  include  tools  to  access 
and  combine  requisite  data  from  the  design,  manufacturing,  and  diagnostic  databases  in 
formats  appropriate  for  the  “authoring”  task. 

2.1.  COST  AVOIDANCE 

The  figures  below  are  based  on  a  typical  aircraft  organizational  level  T.O.  library. 

We  estimate  that  automation  support  of  the  types  of  tools  described  in  this  document  could 
yield  a  T.O.  cost  saving  on  the  order  of  35  to  40  percent  over  the  life  cycle  of  typical  weapon 
systems.  This  assumes  that  all  engineering  data  is  in  the  proper  format  to  begin  with  (e.g., 
CAD  models  in  solids,  all  systems  modeled  in  Computer  Aided  Manufacturing  tools,  RDM  in 
place  at  the  component  level). 

2.1.1.  Locating  and  Tracking  Data 

We  estimate  that  about  twenty-six  percent  of  an  author's  time  is  spent  locating  and 
tracking  the  data  required  to  produce  T.O.s.  (See  Figure  2.2.)  Once  all  the  data  required 
is  located  and  the  procedures  are  written,  the  T.O.  content  must  be  monitored  for  design 
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changes.  A  working  Product  Data  Manager  might  save  as  much  as  50  percent  of  this 
effort. 


Authoring  Effort  Breakdown 


LOCATING  AND  TRACKING  DATA  (26%) 
RESEARCHING 

AND  ASSEMBLING  DATA  (49%) 
ENTERING  DATA  (25%) 


Figure  2.2.  Breakdown  Of  Typical  Authoring  Effort 


2.1.2.  Researching  and  Assembling  Data 

Researching  the  data  from  the  various  sources  and  writing  the  procedures 
consumes  about  49  percent  of  the  author's  time.  Assembling  this  data  from  the  various 
sources  and  presenting  it  to  the  author  in  a  logical  format  could  reduce  this  effort  by  about 
15  to  25  percent,  depending  on  the  type  of  data  being  authored.  See  Figure  2.3.  for 
average  breakdown  of  T.O.  data. 


T.O.  Data  Breakdown 

□  PROCEDURAL  DATA  (52%) 

/  \ 

/  \  cm  SCHEMATIC  DATA  (10%) 

(  ^ 

iQ  24%j  □  descriptive  DATA  (14%) 

\  52% 

\  /  cm  CHECKOUT  & 

TROUBLESHOOTING  DATA  (24%) 

Figure  2.3.  Typical  Breakdown  Of  T.O.  Data 


2. 1.2.1.  Procedural  Data 

Authoring  procedural  data  (e.g.,  removal  and  installation  of  components)  involves 
generating  text,  graphics,  and  associated  parts  information  required  to  perform  the  task. 
Tools  that  would  allow  the  author  to  graphically  simulate  the  procedure  while  automatically 
linking  the  text  to  the  graphic  and  the  parts  data  could  substantially  reduce  the  time  needed 
to  create  maintenance  procedure  documentation. 
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2. 1.2. 2.  Schematic  Data 

The  time  required  to  generate  schematics  could  be  reduced  by  about  20  percent  if 
authored  in  a  “connectivity”  based  system.  The  system  would  use  the  engineering  wiring 
database  for  physical  connectivity  and  the  software  connectivity  from  engineering  CASE 
tools. 

2. 1.2. 3.  Testing  And  Troubleshooting  Data 

By  using  the  data  derived  from  engineering  CAE  and  reliability  analysis  tools,  the 
authoring  of  testing  and  troubleshooting  data  could  be  reduced  by  as  much  as  20  to  25 
percent.  Data  accuracy  could  also  be  improved. 

2.1.3.  Entering  Data 

The  process  of  manually  keying  the  data  into  the  authoring  system  consumes  about 
25  percent  of  the  author's  time.  It  is  likely  that  some  degree  of  manual  labor  will  be  required 
no  matter  how  automation  support  for  T.O.  creation  evolves.  But  the  nature  of  the 
“authoring”  task  will  dramatically  change  to  emphasize  consistency  and  other  quality 
checking  elements  of  production  rather  than  original  creation  of  text  and  graphical  material. 

2.2.  REDUCING  TIME  LAG 

Automation  will  reduce  lag  time  in  the  area  of  design  data  location,  extraction,  and 
the  insertion  of  that  data  into  a  T.O.  Refer  to  Cost  Avoidance  in  this  section  for  reduction 
percentages. 

Automation  will  provide  the  author  with  the  greatest  time  saving  in  the  areas  of 
locating  and  tracking  engineering  design  data.  Automation  concepts  that  use  Product  Data 
Management  will  provide  access  to  all  relevant  data  required  by  the  author  from  one  source. 
The  availability  of  the  data  to  the  author  immediately  after  engineering  release  also  helps  to 
reduce  the  time  lag. 

2.3.  QUALITY  AND  ACCURACY 

Automation  impacts  the  quality  and  accuracy  of  T.O.  products  in  different  ways. 
Quality  deals  more  with  the  completeness  of  the  data  and  compliance  with  contract 
specifications  Accuracy  deals  with  the  technical  correctness  of  the  data. 

Quality  assurance  will  demand  time  and  effort  regardless  of  what  types  of 
automation  support  T.O.  creation.  Yet  it  seems  likely  that  some  of  the  tasks  involved  in 
quality  control  can  themselves  be  automated.  Automatic  word  processing  programs 
include  spell  checking  and  grammar  flagging.  Advanced  T.O.  generation  systems  could 
include  analogous  tools  for  evaluating  wiring  diagrams/schematics,  verifying  task  step  logic, 
and  so  on. 
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2.4.  LEGACY  DATA 

Various  types  of  engineering  data  for  previous  systems  can  be  recruited  for 
maintenance  T.O.  documents  for  new  systems.  Legacy  design  engineering  data  exists  in 
the  form  of  paper  or  electronic  media.  Existing  tools  that  convert  paper  documents  to 
electronic  media  using  semantic  and  graphic  recognition.  Converting  the  heterogeneous 
legacy  data  into  a  format  compatible  with  engineering  tools  (e.g.,  CAD  models  in  solids, 
virtual  manufacturing  tools,  computer-aided  engineering  tools)  is  time  consuming  and  costly. 
Yet  not  populating  the  engineering  tools  with  the  legacy  data  would  leave  holes  in  the 
engineering  data  model.  This  would  require  additional  automation  tools  to  work  around  the 
problem.  These  additional  tools  would  require  a  considerable  amount  of  authoring  time  to 
transfer  the  disparate  data  elements  into  a  T.O.. 

2.5.  TECHNOLOGY  REQUIREMENTS 

2.5.1.  Current  State 

Engineering  automation  tools  provide  a  means  of  collecting  the  data  needed  to 
develop  T.O.s.  However,  these  tools  have  not  yet  been  fully  tested  in  the  context  of  T.O. 
production.  A  pacing  problem  is  the  apparent  lack  of  data  exchange  standards  that  would 
assure  data  integrity  between  different  analysis  applications.  In  addition,  most  of  the 
currently  available  tools  do  not  include  data  managers  capable  of  tracking  aircraft 
configuration  changes.  This  is  especially  troublesome,  since  configuration  changes 
affecting  maintenance  occur  throughout  the  life  cycle  of  aircraft  systems,  not  just  during 
original  design. 

2.5.2.  Steps  to  Reach  the  Future  State 

The  use  of  a  Product  Data  Manager  is  probably  the  most  significant  step  in  reaching 
the  goal  of  automatically  deriving  data  from  engineering  tools  for  use  in  a  T.O.  The  PDM 
would  track  all  part  hierarchy  and  effectivity  information  and  maintain  the  relationships  of 
engineering  database  files.  The  continued  development  of  data  exchange  standards  for 
functional  simulation  tools  is  required  to  data  exchange  between  the  engineering 
CAE/CASE  tools.  As  noted,  this  is  a  problem  of  unstable  or  loose  standards  which  allow 
flexibility  in  tool  design,  but  hinder  exchange  of  data  between  tools.  The  lack  of  data 
exchange  standards  limits  the  potential  pay  back  from  investments  in  automation  tools. 
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3.0.  TECHNICAL  ORDER  AUTHORING  REQUIREMENTS 


3.1 .  TECHNICAL  ORDER  CONTENT  STRUCTURE 


The  structure  of  modern  T.O.s  is  based  on  a  functional  system  breakdown.  Each 
system  contains:  descriptive  information,  part  information,  fault  information,  and  task 
information. 

3.1.1.  Descriptive  Information 

Defines  general  purpose,  non-procedural,  narrative  information  such  as  theory  of 
operation  or  physical  descriptions  of  a  system. 

3.1.2.  Part  Information 

Describes  the  maintainer’s  view  of  the  part  by  identifying  its  relative  position  in  the 
aircraft  system/subsystem  hierarchy.  Part  information  contains  supply  system  data; 
equivalent  parts,  sub-parts,  part  connections,  and  attachments  with  larger  assemblies. 

3.1.3.  Fault  Information 

Defines  all  of  the  tests,  faults,  and  rectifications  associated  with  the  system.  Tests 
evoke  tasks  that  identify  how  to  perform  the  test,  and  outcomes  that  define  the 
discrepancies  found  during  the  test.  The  outcomes  have  expressions  which  when 
evaluated,  identify  either  a  fault  state  for  dynamic  fault  isolation;  or  a  fault  or  test  in  a  static 
fault  structure. 

Fault  isolation  data  is  provided  by  a  troubleshooting  tree  where  the  maintainer  is 
directed  down  a  prescribed  isolation  and  maintenance  path  to  correct  the  problem.  The 
maintainer  will  typically  begin  with  a  test  which  will  lead  him  to  a  fault.  The  rectification  for 
that  fault  is  then  displayed.  A  verification  test  is  then  called  for. 

3.1.4.  Task  Information 

A  maintenance  task  is  a  set  of  directed  steps  that  together  make  up  a  logical  work 
sequence.  It  is  common  to  describe  this  work  as  either  corrective  (i.e.,  fix  something)  or 
preventive  (i.e.,  avoid  something  breaking).  These  tasks  are  documented  with  simplified 
text,  line  art,  tables,  and  references.  The  procedures  are  described  in  step-by-step 
sequence,  generally  using  action  words  (e.g.,  remove,  check,  tighten)  against  objects  (e.g., 
bolt,  panel,  nozzle).  Warnings  and  cautions  are  interspersed.  Required  support  equipment 
and  tools  are  always  specified.  The  task  is  illustrated  through  various  types  of  line 
drawings,  schematics,  and  other  visual  aids. 
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4.0.  EXISTING  INFRASTRUCTURE  AND  PROCESS  (OVERVIEW) 


4.1.  RESEARCH 

We  estimate  that  about  75  percent  of  a  T.O.  author's  time  is  spent  locating,  tracking, 
and  researching  system  data.  This  process  extends  over  the  entire  development  cycle. 
Through  research,  the  author  collects  and  evaluates  information  to  gain  a  comprehensive 
knowledge  of  the  component  or  system.  This  includes  its  operating  principles,  use, 
materials,  and  maintenance  requirements. 

The  amount  of  data  available  to  the  author  depends  on  the  developmental  state  of 
the  component.  During  early  development,  the  author  will  be  limited  to  information  sources 
such  as: 

Design  specifications  Models 

Design  data  books  Mock  ups 

Engineering  design  sketches  Personal  working  relationships  with  designers 

As  development  progresses  through  production,  delivery,  and  use  of  the  equipment, 
research  for  the  T.O.  expands  into  areas  such  as: 

Engineering  drawings  Time  compliance  technical  orders 

Engineering  orders  Publication  change  requests 

Engineering  change  proposals  Field  service  trouble  reports 

Vendor  data  Government  furnished  data 

4.2.  SOURCES  OF  DATA 


As  multiple  legacy  systems  are  used  to  design,  analyze,  and  manufacture  a  product 
throughout  the  product  life  cycle,  different  pieces  of  product  data  are  created  by  a  variety  of 
tools  (See  Figure  4.1).  These  data  are  stored  on  paper  or  in  files  or  databases  which  reside 
on  multiple  electronic  media. 

The  difficulty  of  collecting  source  data  is  sometimes  exacerbated  by  the  wide  variety 
of  packaging  formats.  Paper  and  diskettes,  mircofiche  and  CD-ROM,  engineering  reports 
and  specifications:  the  real  world  shows  a  disconcerting  mix  of  source  data.  Locating  and 
accessing  source  data  is  a  time  consuming  problem.  Indeed,  it  can  take  as  much  time  to 
merely  assemble  the  required  data  as  it  does  to  generate  the  T.O.  products  which  depend 
on  it. 


Once  the  source  data  is  accummulated,  the  T.O.  author  must  establish  configuration 
control  process  for  the  data.  All  data  used  must  be  systematically  re-accessed  and 
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evaluated  to  ensure  that  the  most  recent  data  are  incorporated  into  the  maintenance 
manuals.  This  process  is  exercised  throughout  the  product  life  cycle. 


The  following  data  sources  of  data  are  used  in  the  development  of  T.O.  data.  The 
data  is  broken  down  by  the  major  categories  of  information  provided  in  a  T.O.  (e.g., 
DESCRIPTIVE,  PROCEDURAL,  FAULT,  PART) 


5.0.  FUTURE  INFRASTRUCTURE  AND  PROCESS  fOVERVIEWt 

5.1 .  DESIGN  TOOL  OVERVIEW 

5.1.1.  Computer  Aided  Engineering  fCAE) 

Figure  5.1  illustrates  how  design  engineers  use  CAE  tools.  These  tools  enable  the 
designer  to  select  component  models  from  a  library  and  connect  them  to  represent  the 
functional  design  of  the  system.  In  the  conceptual  phase  of  design,  these  models  are  often 
based  on  similar  existing  components  that  provide  the  same  (or  similar)  functions.  As  the 
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design  matures,  new  components  may  have  to  be  designed  and  modeled  for  the 
component  library.  Included  in  the  component  models  are  parameters  about  the 
component,  such  as  pressure,  flow  rates,  power  requirements,  failure  modes,  inputs, 
outputs,  and  so  on.  Once  the  system  model  is  developed  from  the  component  models  and 
their  connectivity,  some  CAE  tools  allow  simulation  of  the  system  functions.  This  same 
simulation  also  provides  logistics  analysts  the  ability  to  simulate  failures  of  individual 
components  and  to  determine  their  effects.  These  failure  modes  and  effects  analyses 
(FMEA)  define  the  maintenance  tasks  that  will  be  required.  The  maintenance  task  analysis 
data  (manpower,  tools,  and  support  equipment,  etc.)  are  ultimately  tied  to  this  FMEA. 


Figure  5.1  Example  of  CAE  Tool  Display 

Maintenance  task  analysis  data  can  also  be  produced  using  a  simulation  approach 
early  in  design  development,  before  hardware  is  fabricated.  We  foresee  a  number  of  CAD- 
based  visualization  technologies  supporting  this  capability.  One  of  these,  human  form 
modeling,  can  provide  early  identification  of  maintenance  problems  and  highlight  possible 
solutions  for  CAD  engineers.  For  example,  if  a  component  to  be  removed  is  shown  through  3- 
D  CAD  animation  to  be  obstructed  by  other  components,  it  might  be  relocated  or  perhaps 
redesigned  to  assure  ease  of  removal.  If  a  simulated  maintenance  person  in  the  CAD 
environment  cannot  easily  reach  a  component,  we  can  suggest  possible  work  arounds  for  the 
problem.  Maintenance  procedures  verified  and  perhaps  improved  with  this  sort  of  simulation 
could  then  be  passed  to  the  authoring  process  for  incorporation  into  maintenance  T.O.s.  (See 
also  Section  8  below.) 

5.1.2.  Computer  Aided  Design  (CAD) 

Once  the  hardware  functional  design  is  approved,  the  physical  part  of  the  design 
process  begins.  The  system  components  are  either  procured  or  manufactured  based  upon 
the  design  requirements.  CAD  tools  are  used  to  assist  in  these  efforts  (See  Figure  5.2). 
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These  tools  define  the  assembly  of  the  various  components  into  the  final  product.  The  data 
contained  in  these  systems  are  the  appearance  of  the  part,  location,  part  number,  and  any 
parts  required  to  attach  one  part  to  another.  As  indicated  above,  CAE  siimulation  and 
virtual  reality  tools  are  being  integrated  with  the  CAD  systems  to  test  the  physical  design 
component  interference  and  maintainability  prior  to  physical  design  approval.  These 
physical  models  have  the  potential  to  eliminate  the  physical  mockups  that  were  built  prior  to 
production.  Most  new  products  in  aerospace,  automotive,  and  related  manufacturing 
industries  are  being  designed  and  engineered  with  CAD/CAE  technologies.  This 
automation  format  is  probably  the  most  important  development  for  T.O.  generation  in  the 
future. 


CAD  (Physical)  CAM  (Physical) 


Figure  5.2  CAD  Tool  Example 


5.1.3.  Computer  Assisted  Software  Engineering  (CASE) 

Just  as  CAE  tools  are  being  developed  to  assist  in  the  development  of  the  functional 
design  for  hardware  components,  CASE  tools  are  being  developed  to  assist  in  the 
development  and  documentation  of  computer  software  (See  Figure  5.3).  These  tools 
enable  the  software  design  engineer  to  graphically  depict  the  software  flow,  to  test  the 
software  through  simulation  and  to  generate  the  code  using  automatic  code  generation 
tools.  These  tools  assist  to  shorten  the  software  development  time.  At  the  organizational 
level  of  maintenance,  the  operation  of  the  weapon  system  is  more  dependent  upon  software 
than  the  hardware  of  the  computers.  The  software  function  must  be  integrated  with  the 
hardware  function  to  determine  the  overall  functional  operation.  The  integration  of  the 
software  and  hardware  will  determine  how  the  system  operates  and  the  extent  to  which  the 
system  can  monitor  and  record  diagnostic  information. 
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Figure  5.3  CASE  Tool  Example 

5.2  SOURCE  TO  DATA  MAPPING 

5.2.1.  CAE  to  Technical  Order  Data  Elements 


Computer  Aided  Engineering  and  Computer  Aided  Software  Engineering  tools  are 
the  source  of  functional  design  information  to  populate  the  following  T.O.  data  elements: 

•  System  Description 

•  Functional  Operation 

•  Tests 

•  Fault  Isolation 

•  Schematics 

5.2.1. 1.  System  Description 

The  component  parameters  contained  in  the  component  library  of  the  CAE  tool;  such 
as  pressure,  flow  rates,  power  requirements,  failure  modes,  inputs,  outputs,  etc.  have  the 


15 


potential  of  providing  inputs  for  the  descriptive  information  elements  of  the  T.O..  These 
could  be  used  to  help  describe  the  functional  characteristics  of  each  component  within  the 
system. 

5.2.1. 2.  Functional  Operation 

The  connectivity  defined  in  the  CAE  tools,  along  with  the  parameters  associated  with 
the  components,  define  how  the  components  interact  with  one  another  to  provide  system 
functionality.  The  model  representation  of  the  system  can  be  used  as  the  source  for  the 
development  of  the  operational  description. 

5.2. 1.3.  Test  Information  and  Fault  Isolation 

Based  upon  the  functional  operation  depicted  in  the  design  models  and  the 
simulation  capabilities,  the  CAE  tools  are  also  the  source  for  test  information  and  the 
resulting  outcome  expressions.  These  are  derived  from  the  failure  modes  and  effect 
analysis  part  of  the  design  process.  Based  upon  the  Failure  Modes  and  Effect  Analysis 
(FMEA),  the  appropriate  maintenance  task  or  test  is  determined.  These  are  inputs  into  the 
dynamic  or  static  fault  structure  of  the  T.O.  The  fault  structure  can  be  derived  based  upon 
the  connectivity  (dependencies)  linked  to  the  diagnostics  design  of  the  system. 

Fault  data  contains  all  tests,  faults,  and  rectifications  for  a  system.  A  test  is  a 
diagnostic  procedure  designed  to  help  the  maintainer  troubleshoot  weapon  system 
problems.  Tests  will  drive  the  maintainer  to  a  fault  and  associated  rectification. 

The  Computer  Aided  Engineering  (CAE)  tools  enable  design  engineers  to  design 
and  simulate  aircraft  system  operation  (See  Figure  5.4).  These  tools  are  being  enhanced  to 
provide  FMEA  authoring  within  the  tool. 


Figure  5.4.  Example  of  CAE  Display 
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The  tool  allows  the  engineer  to  fail  a  component  and  observe  the  overall  effects  on 
the  system.  The  resulting  FMEA  data  (Table  5.1)  provides  the  information  required  to 
support  the  generation  of  fault  isolation  data  to  be  used  in  the  T.O. 

Table  5.1.  FMEA  Data  Needed  to  Generate  Fault  Isolation 


LRU 

SRU 

Failure 

Mode 

Failure  Effects 

LRU 

SYS 

Pump 

Motor 

Open 

Press  < 1800 

Light  Off 

Trap  Will  Not  Trip/Reset 

Pump 

Motor 

Closed 

Press  >  1800 

Light  On 

Pump  operates  Continuously 

Relay  Coil 

Coil 

Open 

Press  > 1 800 

Light  Off 

Trap  will  Not  Trip 

Relay 

Coil 

Closed 

Press  <1800 

Light  On 

Trap  will  Not  Reset 

Valve 

Coil 

Open 

Press  > 1 800 

Light  Off 

Trap  will  Not  Trip 

Valve 

Coil 

Closed 

Press  > 1800 

Light  On 

Trap  will  Not  Reset 

Wiring  -  Splice  to  Relay 
Coil 

Open 

Press  > 1800 

Light  Off 

Trap  will  Not  Trip 

Wiring  -  Panel  Splice  to 
Relay  Sw 

Open 

Press  > 1800 

Light  Off 

Trap  will  Not  Trip 

Combining  all  like  failure  effects  of  each  component  in  the  system  will  provide  a  list 
of  all  Line  Replaceable  Units  (LRU's)  whose  failure  would  cause  the  failure  effect.  (See 
Table  5.2).  These  data,  when  linked  to  Logistic  Support  Analysis  (LSA)  fault  data,  can 
provide  additional  information  such  as  access  times  and  maintenance  levels  for 
repair/replacement. 
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Table  5.2.  Fault  Data  from  FMEA  and  LSA 


Fault  Description 

Fault 

Fail  Mode 

MTBF 

ACCESS 

Press  >  1800 

Pump  Motor 

S-Gnd 

Light  On 

Wiring 

Pump  Operates  Continuallv 

Pump  To  Accum  Sw 

S-Gnd 

Press  > 1800 

Relay 

Open 

Light  On 

Accum  Sw 

Open 

Trap  Will  Not  Trip 

Valve 

Open 

Trip  Sw 

Open 

Wiring 

Spiice  To  Reiay  Coii 

Open 

Relay  Sw  to  Valve 

Open 

Panel  Splice  To  Reiay 

Sw 

Open 

Accum  Sw  To  Trip  Sw 

Open 

Reiay  To  Accum 

Open 

Trip  Sw  To  Ground 

Open 

Valve  To  Ground 

Open 

Press  >  1800 

Relay 

Closed 

Light  On 

Wiring 

Trap  Trips  Pwr  On 

Resets  Pwr  Off 

Relay  To  Valve 

S-Pwr 

Using  the  fault,  TRAP  WILL  NOT  TRIP,  PRESS  >  1800  and  LIGHT  ON  from 
Table  5.2,  the  tool  could  provide  a  list  of  all  components  that  could  cause  the  fault,  in  most 
probable  order,  with  access  times  identified  for  reference.  The  tool  could  also  display  the 
affected  area  of  interest  for  reference  in  developing  the  troubleshooting  procedun 


RES 


28 

VDC 


Figure  5.5.  Example  Of  Area  Of  Interest  Display 
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The  level  of  detail  for  the  area  of  interest  (Figure  5.5)  could  then  be  expanded  to 
provide  greater  detail  of  a  specific  area.  This  could  be  done  as  the  author  generates  the 
individual  tests  required  to  isolate  the  failed  part.  (Figure  5.6) 


GENERATOR/ 

RECTIFIER 


Figure  5.6.  Expanded  Level  of  Detail  Supporting  Individual  Tests 


To  allow  all  faults  to  be  grouped  by  failure  effects,  fault  description  must  be 
consistent  (i.e.,  trap  fails  to  trip  vs.  trap  does  not  operate  vs.  trap  does  not  actuate).  Fault 
description  should  be  auto  generated  by  the  FMEA  tool  whenever  possible 

Fault  description  must  be  provided  by  reportable/observable  indications  (i.e.,  Pilot 
Observable,  Data  Storage  Unit,  Maintainer  Observable,  etc.) 

5.2. 1.4.  Schematics 

The  transition  of  design  communities  to  CAE  and  CASE  tools  provides  the  Technical 
Publication  community  with  the  ability  to  import  design/engineering  data  into  a  T.O. 
authoring  system.  These  tools  contain  the  connectivity  and  functionality  of  an  entire 
system.  In  essence,  these  tools  contain  the  same  technical  data  as  schematics  delivered  in 
a  paper  form  today.  A  separate  schematic  tool  could  extract  the  necessary  design  data, 
and  import  that  data  into  an  T.O.  authoring  system.  The  schematic  tool  could  then  either 
automatically,  or  with  some  manual  authoring,  generate  a  T.O.  schematic. 

5.2.2.  CAD  To  Technical  Order  Data  Elements 


Computer  Aided  Design  tools  could  become  the  source  for  physical  design 
information  to  populate  the  following  T.O.  data  elements; 

•  Graphic  (model)  Representation 

•  Physical  Description 

•  Physical  Operation  (Mechanical  Controls) 

•  Procedural  Tasks  (Remove,  Install,  Adjust) 

•  Part  Information 
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5. 2. 2.1.  Graphic  (Model)  Representation 

The  graphic  model  of  the  component,  whether  developed  by  the  supplier  or  by  the 
prime  contractor,  depicts  the  physical  aspects  of  design  and  can  be  linked  as  applicable 
from  a  multitude  of  T.O.  data  elements.  There  are  three  basic  types  of  graphics  models 
representing  the  component; 

•  Locator  graphics  which  show  the  location  of  a  part  within  the  system 

•  Detailed  graphics  which  show  the  component  from  different  views  for  descriptive 
purposes 

•  Parts  breakdown  graphics  that  depict  the  parts  which  connect  to  or  attach  the 
component  to  other  components. 

52.2.2.  Defining  the  Graphic  Parameters. 

Automated  generation  of  graphics  would  require  development  of  software  to 
assemble  and  display  graphics  matching  the  defined  parameters  (graphics  parts  list  and 
viewpoint)  (See  Figure  5.7).  The  objective  would  be  to  use  part  geometry  data  from  design 
databases  to  create  the  graphic  image  rather  than  duplicate  part  geometry  in  a  separate 
file.  The  output  would  be  a  displayed  graphic  and/or  Computer  Graphics  Metafile  (CGM). 

If  the  part  geometry  is  modeled  in  solids,  it  is  feasible  that  the  assembled  graphic 
would  require  no  manual  clean-up,  such  as  removal  of  hidden  lines.  The  first  step  in 
generating  a  graphic  is  to  define  its  parameters.  These  parameters  will  define  viewpoint 
and  the  parts  to  be  included  (the  graphic  parts  list).  Viewpoint  can  be  made  straightfon/vard 
by  allowing  a  predetermined  set  of  views,  such  as  looking  down  and  aft  at  right  hand  side. 
Generating  the  graphics  parts  list  could  be  accomplished  by  several  methods: 

•  Directly  entering  the  list  of  desired  parts. 

•  Using  the  parts  structure  database  to  generate  the  list  by  assembly  numbers  and 
effectivity. 

•  Using  spatial  data  to  list  parts  within  defined  aircraft  coordinates. 

•  Once  an  initial  list  is  generated  it  would  be  possible  to  further  refine  the  list  until  the 
desired  result  is  achieved. 
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5. 2.2. 3.  Physical  Description 

The  detail  graphic  and  the  locator  graphic  can  be  used  as  a  source  to  describe  the 
physical  location  and  appearance  of  the  component  as  it  applies  to  a  specific  weapon 
system. 


5.2.2.4.  Physical  Operation 

The  Illustrated  Parts  Breakdown  (IPB)  type  graphic,  which  shows  the  physical 
connectivity  of  one  component  to  another,  can  be  used  to  depict  the  mechanical  operation 
of  a  system.  Used  in  conjunction  with  virtual  reality  and  model  simulation  tools,  these 
graphics  models  become  the  source  for  the  operational  description  of  the  system. 

5.2.2.5.  Procedural  Tasks  (Remove,  Install,  Adjust) 

CAD  systems  have  four  data  elements  that  are  of  interest  in  developing  an  outline  of  a 
procedural  task:  component  identification,  connecting  parts,  attaching  parts,  and  interference 
identification.  A  tool  could  be  developed  to: 

•  Rotate  the  CAD  models  to  the  closest  view  for  the  task  ( i.e.,  looking  inboard, 
outboard,  forward,  or  aft). 

•  Determine  if  the  component  can  be  moved  in  the  direction  of  the  point  of 
view.  If  it  can't,  is  interference  caused  by  an  access  door  part?  If  it  can,  then 
add  step  "Open/remove  door."  If  it  can’t,  try  various  angles  to  eliminate 
interference.  If  interference  no  longer  exists,  add  as  the  last  step  "Rotate 

component _ degrees  and  remove."  If  interference  still  exists,  add  Required 

Condition  "Remove  component  ?"  If  interference  no  longer  exists  or  never 
existed,  then  check  for  connecting  and  attaching  parts.  If  connecting  parts, 
add  step(s)  "Disconnect  ?".  If  attaching  parts,  then  add  step(s) 
"Remove/Loosen  ?".  After  all  connecting  and  attaching  parts  are  addressed, 
add  step  "Remove  ?" 
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5. 2. 2. 6.  Parts  Information 

Parts  data  provides  the  information  required  to  identify  and  order  all  repair  parts.  As 
parts  are  identified  by  design  engineering,  they  are  logged  in  the  PDM  identifying  parts 
usage.  Once  in  the  product  data  manager  and  released,  the  Provisioning  Group  researches 
the  part  for  equivalents,  assigns  recommended  nomenclature,  assigns  Source  Maintenance 
and  Recoverability  (SM&R)  code.  Commercial  And  Government  Entity  (CAGE)  code,  etc. 
and  forwards  to  Defense  Logistics  Services  Center  (DISC)  for  Screening.  DISC  assigns 
the  National  Stock  Number  (NSN),  approves/changes  recommended  nomenclature  as 
required  and  returns  the  updated  parts  information  to  the  contractor  (See  Figure  5.8). 


PROVDATA  INPUT 
SYSTEM 


T.O. 

DOCUMENT 

FILES 


Figure  5.8.  Parts  Data  Generation. 

The  job  of  the  Product  Data  Manager  is  to  maintain  the  relationships  of  database 
files.  It  would  contain  all  part  hierarchy  and  effectivity  information.  As  a  single  source  for 
production  and  post-production  configuration  management,  the  product  data  manager  could 
feed  automated  generation  of  T.O.  graphics  and  illustrated  parts  breakdowns.  The  T.O. 
author  would  pull  up  the  engineering  "build-to"  package  (paragraph  5.3.2.3).  Modify  the 
drawing  in  CAD  if  required  and  promote  the  drawing  for  use  in  T.O.s.  The  process  of 
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promoting  the  drawing  would  create  links  to  the  PDM,  extract  all  part  geometry  from  the 
engineering  CAD  system,  assign  index  numbers  to  part  geometry,  associate  part 
information  to  the  index  numbers,  and  create  a  T.O.  graphic  file.  The  parser  compares  the 
part  information  to  the  existing  T.O.  data  base.  It  then  eliminates  duplicate  parts  and 
sends  all  new  parts  to  the  provisioning  parser  to  add  required  provisioning  info  (CAGE, 
SM&R,  equivalent  parts,  etc.).  The  parser  then  moves  the  part  data  into  the  T.O.  and 
updates  the  PDM  with  T.O.  version  data  (See  Figure  5.9). 


Figure  5.9.  Parts  and  Graphic  Linking 
5.3.  CONFIGURATION  CONTROL 

The  manufacturing  industry  has  made  significant  investments  in  information 
technologies  (IT)  to  automate  various  processes  in  the  product  life  cycle.  These 
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investments  are  seen  in  the  rapid  growth  of  the  computer-aided  design,  manufacturing, 
engineering,  and  computer-integrated  manufacturing  (CAD/CAM/CAE/CIM)  market.  The 
industry  has  been  hampered  by  a  phenomenon  known  as  "islands  of  automation” 
characterized  by: 

•  Maintenance  of  incompatible  data  definition  formats.  A  number  of  translators 
are  required  to  allow  data  files  to  be  shared  between  different  systems. 

•  The  need  to  retain  separate  views  of  the  product  structure  using 
engineering,  manufacturing,  and  product  support  parts  data  (EBOM, 
MBOM,  provisioning  and  illustrated  parts  breakdown). 

•  The  rapid  generation  of  large  quantities  of  design  data  that  makes  manual 
control  of  these  data  extremely  difficult. 


As  a  result,  the  maintenance  cost  for  legacy  systems  remains  a  major  expenditure 
for  a  typical  manufacturing  company.  Consequently,  the  focus  must  shift  to  managing  the 
data  sets  generated  by  these  tools. 

In  an  attempt  to  tackle  this  effort,  a  new  class  of  applications,  called  Product  Data 
Managers  (PDM)  are  required  to  allow  configuration  management  of  almost  any  type  of 
data  set.  (See  Figure  5.10)  The  PDM  relates  all  of  the  data  relevant  to  a  particular 
product/part.  It  does  this  using  a  product  viewpoint. 

•  Product  Structure  Configuration  Management  -  Provides  a  set  of  functions  to 
maintain  various  configurations  of  the  product  definition  data:  associating  data 
sets  to  parts  of  a  given  assembly;  traversing  the  Bill  of  Materials  (BOM) 
through  explosion  or  implosion;  applying  effectivity  to  parts  of  a  given 
installation;  creating  virtual  assemblies  by  instancing  component  geometry. 


•  Group  Technology  and  Parts  Library  -  Provides  a  set  of  functions  to  classify 
and  group  parts  to  increase  accessibility  and  reusability:  maintaining  universal 
parts  codes;  maintaining  standard  component  libraries. 

•  Data  Conversion  -  Provides  a  set  of  functions  to  present  the  requested  data 
to  the  user  in  proper  format  on  the  target  device:  automatically  invoking  the 
proper  translator  for  data  format  translation;  performing  proper  conversion  in 
a  multimedia  environment. 


•  Program  Management  -  Provides  a  set  of  functions  to  define  the  business 
processes  and  manage  the  project  based  on  a  given  process:  defining 
processes  based  on  a  standard  process  modeling  methodology;  maintaining 
Work  Breakdown  Structure  (WBS)  and  networks;  performing  resource 
scheduling;  monitoring  project  status. 
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•  T.O.  Authoring  Support  -  Provides  a  set  of  functions  to  make  product 
information  readily  available  to  support  T.O.  authoring:  automatically 
generating  the  information  by  extracting  raw  data  based  on  user  specified 
criteria;  and  maintaining  traceability. 

Configuration  control  automates  tedious  bookkeeping  tasks  and  helps  authors 
develop  T.O.  data  smoothly.  Using  a  configuration  control  tool,  authors  can  track  each 
change  to  the  source  data  and  associate  T.O.  data  with  each  change.  It  can  ensure  that 
authors  are  working  with  the  most  current  source  data  and  that  they  do  not  overwrite 
changes.  The  system  can  easily  determine  what  T.O.  data  has  been  changed  and  why  the 
change  was  made.  This  information  is  especially  useful  for  audit  purposes  by  providing 
detailed  documentation  for  every  change.  In  summary,  configuration  control  for  T.O.  data  is 
required  to  ensure  that  the  source  data  used  is  the  latest  and  most  accurate  data  available. 
This  is  accomplished  by  providing: 

•  Providing  visibility  over  the  change  process  through  change  and  difference  reports, 

•  Ensuring  authors  are  working  with  the  most  current  version  of  code, 

•  Preventing  data  from  moving  to  the  next  phase  without  completing  ail  required 
approvals, 

•  Ensuring  that  concurrent  changes  to  the  same  item  are  merged  and  prevent  change 
regression, 

•  Allowing  different  functional  groups  to  work  on  the  same  application  in  parallel 

•  Streamlining  the  release  cycle, 

•  Allowing  older  releases  to  be  maintained  concurrent  with  a  new  release,  and 

•  Eliminating  unwanted  changes  by  ensuring  a  single  path  by  which  changes  can  enter 
production. 
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6.0. 


ISSUES 


6.1.  COMPATIBILITY 

Compatibility  between  different  design  tools  presents  a  major  obstacle  for 
automation  of  T.O.  processes.  Better  standards  seem  to  be  a  prerequisite  for  progress. 

6.2.  CLASSIFIED,  PROPRIETARY,  AND  COMPANY  SENSITIVE  DATA 

Obtaining  classified,  proprietary  and  company  sensitive  data  has  been  a  problem  in 
the  past  resulting  in  late  delivery  of  the  data  to  the  field.  A  method  of  filtering  this  type  of 
data  contained  in  design  models  and  tools  needs  to  be  developed  to  support  automation 
concepts. 

6.3.  CONFIGURATION 

Configuration  control  is  also  required  for  technical  data  automation.  All 
configurations  must  be  maintained,  in  a  PDM,  throughout  the  product  life  cycle.  Most  design 
engineering  systems  track  or  maintain  only  the  configuration  currently  in  production.  Field 
modifications  and  retrofits  must  also  be  included  to  assure  data  integrity. 

6.4.  LEGACY  DATA 

The  cost  of  converting  engineering  legacy  data  from  paper  or  other  electronic  media 
to  a  format  suitable  for  technical  data  automation  is  a  continuing  problem. 

6.5.  CONTRACTUAL  APPROVAL 

Engineering  approval  for  contract  changes  to  a  weapon  system  occur  long  before 
publication  approvals  to  incorporate  those  changes  occur.  Engineering  is  consistently 
working  a  multitude  of  contractual  changes,  with  the  possibility  of  each  having  different 
completion  dates.  Hence,  automation  tools  for  maintenance  technical  data  must  have  the 
capability  to  filter  out  configuration  changes  that  have  been  approved  for  engineering,  but 
not  approved  for  T.O.  incorporation. 
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7.0.  SKILLS  REQUIREMENT  EVALUATION 


7.1 .  CURRENT  PAPER  BASED  AUTHORING  SKILLS  REQUIRED 

•  Degree  associated  with  aircraft  maintenance 

•  Experience  in  aircraft  maintenance 

•  Weapons  -  Hands  on 

-  Avionics  background 

•  Avionics  -  Detailed  avionics  training 

•  Can  read  and  understand  schematics 

•  Blueprint  reading 

•  Basic  computer  skills 

•  Knowledge  of  Air  Force/Navy/Army  maintenance  levels  of  repair 

•  Communications  skills,  both  verbal  and  written 

7.2.  AUTOMATED  TECHNICAL  ORDER  -  WITH  AUTHORING  REQUIRED 

•  Degree  associated  with  aircraft  maintenance 

•  Experience  in  aircraft  maintenance 

•  Weapons  -  Hands  on 

-  Avionics  background 

•  Avionics  -  Detailed  avionics  training 

•  Can  read  and  understand  schematics 

•  Blue  print  reading 

•  Basic  computer  skills 

•  Knowledge  of  Air  Force/Navy/Army  maintenance  levels  of  repair 

•  Communications  skills,  both  verbal  and  written 

•  Basic  understanding  of  Database  concepts 

•  Basic  understanding  of  elementary  computer  programming  constraints 

•  Paradigm  shift  of  constructing  instructions  in  an  electronic  media  environment 
verses  traditional  document  composition 


7.3.  AUTOMATED  TECHNICAL  ORDER  -  WITH  NO  AUTHORING  REQUIRED 


•  Degree  associated  with  aircraft  maintenance 

•  Experience  in  aircraft  maintenance 

•  Weapons  -  Hands  on 

-  Avionics  background 

•  Avionics  -  Detailed  avionics  training 

•  Basic  understanding  of  schematics 

•  Basic  blueprint  reading  skills 

•  Basic  computer  skills 

•  Knowledge  of  Air  Force/Navy/Army  maintenance  levels  of  repair 

•  Communications  skills,  both  verbal  and  written 
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•  Basic  understanding  of  database  concepts 

•  Basic  understanding  of  elementary  computer  programming  constraints 

•  Paradigm  shift  of  constructing  instructions  in  an  electronic  media  environment 
verses  traditional  document  composition 

8.0.  GOVERNMENT-FURNISHED  SOFTWARE  TOOLS 


8.1 .  DESIGN  EVALUATION  FOR  PERSONNEL,  TRAINING,  AND  HUMAN  FACTORS 

(DEPTH)  SIMULATION  -  EVALUATION  OF  SOFTWARE 


DEPTH  is  a  software  tool  for  visualizing  and  analyzing  certain  aspects  of 
human/machine  and  human/workplace  interaction  during  the  early  design  process.  The  key 
feature  of  this  CAD-oriented  simulation  tool  is  a  human  form  model  which  replicates  many 
of  the  physical  capabilities  of  real  persons.  The  human  form  model  (derived  from  the  Jack 
model  of  the  University  of  Pennsylvania)  can  be  made  to  interact  with  given  design 
configurations  to  assess  gross  aspects  of  maintainability.  The  idea  is  to  perform 
maintenance  task  analysis  electronically  during  the  early  design  phase  in  parallel  with  other 
sorts  of  engineering  analysis.  In  DEPTH,  simulated  persons  can  be  made  to  act  out  typical 
maintenance  tasks  directly  on  the  CAD  screen.  When  augmented  with  information  about 
the  physical  limits  of  human  performance  and  with  information  about  the  maintenance  task, 
DEPTH  simulation  can  yield  task  analysis  information  that  has  previously  required  hard 
mock-ups  to  obtain. 

DEPTH  is  a  research-based  tool  still  under  development  by  Armstrong  Laboratory. 
Although  there  are  many  refinements  and  extensions  still  needed,  the  outlines  of  a  tool  for 
automated  T.O.  creation  using  DEPTH  technology  are  in  plain  view.  Many  of  the  data 
elements  specified  for  maintenance  task  analysis  of  military  systems  are  also  needed  for 
T.O.  development.  Hence,  extensions  of  DEPTH  technology  to  support  the  T.O. 
automation  problem  are  natural  and  valuable. 

Probe  studies  indicate  that  the  most  difficult  technical  challenge  seems  to  lie  in  the 
automatic  generation  of  maintenance  procedures  (or  task  steps)  from  equipment  definitions 
(or  product  data  models)  in  the  form  of  natural  language.  This  language,  generated  from  a 
technical  domain  known  as  computational  linguistics,  can  be  used  both  to  create  text  for 
incorporation  into  a  T.O.  and  to  mechanize  simulations  of  given  maintenance  tasks  using 
human  form  modeling. 

Another  technical  challenge  lies  in  findings  ways  to  augment  CAD  product  models  with 
information  relevant  to  maintenance  analysis.  Currently,  product  models  convey  mainly 
geometric  data.  They  need  to  contain  part  labels  and  related  lexical  “tags”  to  support 
automatic  extraction  of  maintenance  requirements  and  their  documentation.  Specifications 
and  standards  to  accomplish  this  are  slowly  evolving  in  the  form  of  STEP  (Standard  for  the 
Exchange  of  Product  Data)  and  PDES  (Product  Data  Exchange  using  STEP). 
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A  tool  such  as  DEPTH,  when  integrated  with  a  production  CAD  system,  could  provide 
a  valuable  tool  in  the  area  of  maintainability.  It  would  be  valuable  in  the  testing  of  a  complex 
assembly  during  the  design  phase  prior  to  manufacturing.  However,  developing  these  models 
for  all  replaceable  components  on  a  weapon  system  may  not  be  cost  effective.  Many 
components  are  easily  accessed  and  would  not  require  analysis  at  a  detailed  level.  If  the 
above  recommendations  are  incorporated  into  the  DEPTH  tool,  besides  auto  generating  the 
more  complex  tasks,  a  simplified  authoring  tool  could  be  developed  within  DEPTH.  This  tool 
would  utilize  a  subset  of  the  DEPTH  features  allowing  the  author  to  graphically  create  these 
less  complex  tasks. 

Configuration  control  is  another  area  that  requires  examination.  When  importing  solid 
models  from  CAD  into  simulation  tools  like  DEPTH,  configuration  control  is  required  to  support 
updates  and  identify  the  various  aircraft  configurations.  This  information  could  be  used  to 
notify  the  T.O.  author  of  changes  required  to  the  tasks/graphics  developed  using  the  DEPTH 
tool. 
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ACRONYM  LIST 


ATOG  Automated  Technical  Order  Generation 

BOM  Bill  of  Materials 

CAD  Computer  Aided  Design 

CAE  Computer  Aided  Engineering 

CAGE  Commercial  And  Government  Entity 

CAM  Computer  Aided  Manufacturing 

CASE  Computer  Aided  Software  Engineering 

CGM  Computer  Graphics  Metafile 

CIM  Computer-Integrated  Manufacturing 

DEPTH  Design  Evaluation  for  Personnel,  Training,  and  Human  Factors 

DISC  Defense  Logistics  Services  Center 

EBOM  Engineering  Bill  of  Materials 

FMEA  Failure  Mode  and  Effect  Analysis 

IPB  Illustrated  Parts  Breakdown 

IT  Information  Technologies 

LRU  Line  Replaceable  Unit 

LSA  Logistic  Support  Analysis 

MBOM  Manufacturing  Bill  of  Materials 

NSN  National  Stock  Number 

PDM  Product  Data  Manager 

SM&R  Source  Maintainability  and  Recovery 

T.O.  Technical  Order 

VM  Virtual  Manufacturing 

WBS  Work  Breakdown  Structure 
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APPENDIX  A 


AUTHORING  EFFORT  BREAKDOWN 

The  process  of  authoring  a  Technical  Order  spans  the  entire  contract  period  of  a 
program.  Through  research,  the  author  collects  and  evaluates  information  to  gain  a 
comprehensive  knowledge  of  the  component  or  system.  This  includes  its  operating 
principles,  use,  materials,  and  maintenance.  The  authoring  process  can  be  broken  down 
into  three  major  categories: 

•  Locating  /  Tracking  Data  --  Locating  to  sources  of  the  data  required  to  author 
the  data,  then  tracking  that  source  for  changes. 

•  Researching  /  Assembling  Data  -  The  process  of  interpolating  the  data  to 
create  the  information  required  by  the  technician  to  maintain  the  system. 

•  Entering  Data  --  The  actual  process  of  entering  the  data  into  the  authoring 
system. 

We  mailed  surveys  to  one  hundred  technical  publications  professionals  at  McDonnell 
Douglas  Aerospace  requesting  estimates  of  how  they  allocate  their  time  to  these  tasks. 
Because  the  time  to  perform  the  above  tasks  can  vary  by  the  type  of  data  being 
generated,  the  survey  was  broken  down  by  the  types  of  data  contained  in  a  T.O: 

•  Description  and  Principles  of  Operation 

•  Testing  and  Troubleshooting 

•  Schematics 

•  Procedural  Data 

The  survey  also  collected  information  by  type  system  (avionics  vs.  mechanical)  and  aircraft 
model  (F-15,  F-18,  AV-8,  and  T-45).  Forty  two  people  responded  to  the  survey.  The 
results  are  shown  in  the  accompanying  table. 
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SURVEY  RESULTS  (Continued) 
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